Mappings format is yet from the ETL point of view

    f.mappings_fhirpath_to_column = {
      "code.coding.where(system = 'http://snomed.info/sct').code": 'code_snomed',
      "code.coding.where(system = 'urn:mysystem').code": 'code_mysystem',
    }

Since fhir paths longer/more difficult to read than the dataframe column names choosen by users maybe it would be easier for users to overview/manage the mappings in the other direction (more from the dataframe/analysis point of view) like

    f.mappings_column_from_fhirpath = {
       'code_snomed': "code.coding.where(system = 'http://snomed.info/sct').code" ,
       'code_mysystem': "code.coding.where(system = 'urn:mysystem').code",
    }

Opinions / proposals for better property name?

If no other wishes/proposals would change name and direction to

f.columns_by_fhirpaths = {
  "mycolumnname": "myfhirpath",
  ...

}

• Changed direction and name of mappings like described in comment before

• Integrated FHIR Path extraction with FHIR search to dataframe.

Further plan:

• Integrate FHIR Path extraction to columns with parallel processing of JSON bundles from folder (fhiry.parallel.process)

• Add FHIR Path extraction to usage documentation

Please mark this as done once completed, so that I can merge this. Thanks!

It is done for FHIR bundle files and FHIR search, but (like documented in readme) not yet for ndjson (no time next weeks and not sure if first to add quick and dirty (by copying the code parts from fhiry.py) or better but more long term more DRY (but more effort/have to compare the differences between fhiry.py and fhirndjson.py / maybe some architecture discussion for somehow unifying or inheriting or sharing codeparts between fhiry.py and fhirndjson.py maybe by defining a property with maybe (optional) prefix "resource." for json bundles which not used or empty for import of ndjson (i yet didnt use in FHIR context/yet no experience/deeper look on fhirndjson.py)

I have released a new version with the previous PR. Thanks for the effort!